1. Field of the Invention
This application is a continuation of U.S. patent application Ser. No. 11/077,340, now U.S. Pat. No. 7,484,226, filed on Mar. 10, 2005, by Patrick Joseph Brooks. This invention relates to technologies for assisting in the development of web-based application programs, and especially to development of application programs intended for execution by on-demand computing platforms.
2. Background of the Invention
As business demand increases, the depth of technology improvements and its intelligence to handle multiple processes becomes highly desirable and crucial. In any enterprise operation, it is difficult to effectively manage the ever-fluctuating resources available, while maximizing the resource utilization.
In fact, Information Technology (“IT”) costs can become very expensive when maintaining sufficient resources to meet peak requirements. Furthermore, user inputs are generally required to facilitate such processes, which incurs additional costs in both time and human resource demand.
To address these needs, many large vendors of enterprise computing systems, such as International Business Machines (“IBM”), Hewlett-Packard (“HP”), Microsoft Corporation, and Sun Microsystems (“Sun”), have begun to develop and deploy infrastructure technologies which are self-managing and self-healing. Self-managed infrastructures enable a business model whereby customers or clients have their application programs executed in a manner which consumes a dynamic or time-variant set of resources, thereby allowing the services to be delivered at a cost which is tailored to the actual real-time need or demand for the customer's data processing.
These various self-managed infrastructure initiatives are known by a variety of names. HP's self-managed computing architecture is referred to “Utility Computing” or “Utility Data Center”, while Sun has dubbed their initiative “N1”. IBM has applied terms such as “Autonomic Computing”, “Grid Computing”, and “On-Demand Computing” to their various architecture and research projects in this area. While each vendor has announced differences in their approaches and architectures, each shares the goal of providing large-scale computing systems which self-manage and self-heal to one degree or another.
For example, IBM's Autonomic Computing is a self-managing computing model which is patterned on the human body's autonomic nervous system, controlling a computing environment's application programs and platforms without user input, similar to the way a human's autonomic nervous system regulates certain body functions without conscious decisions.
Additionally, IBM has defined their On-Demand Computing technology as an enterprise whose business processes, integrated end-to-end across the company and with key partners, suppliers, and customers, can respond quickly to any customer demand, market opportunity, or external threat. Throughout our present disclosure, we will refer collectively to these types of new computing infrastructures as “on-demand” systems and architectures.
Developing application programs for these new infrastructures is especially challenging, as many needed logical components are used from other servers on a real-time basis. Testing new application programs can be extremely challenging, as access to a full on-demand system may not be possible or economically feasible, as these systems in their final form tend to be quite large and expensive.
During the creation of web service clients, orchestrated and choreographed service clients, and business processes that leverage web services, it can be extremely difficult to test the client and process functionality in the earlier stages of web services client development. This is because the web services endpoint that the client program will be accessing may have bugs, may still be in development, may be locked behind firewall, or may simply not be accessible during the client development. A web services endpoint can be any computing resource which performs a function on behalf of the client program upon the client program's request, usually based upon data supplied by the client program. Endpoints are often “back office” types of processes and programs which are not intended to interface directly to a human user, but instead are intended to provide some functionality to programs (e.g. client programs) which do interface to the human user, such as calculating mortgage costs, searching for financial instruments, etc.
In order to test web services clients today in the new on-demand computing environments, client programs must access the intended service or a test instance of that service. Actually accessing the endpoint service allows validation that the client program under development implements the web service description accurately, and that the client program can process responses and faults properly. This approach, however, assumes and requires that the client development team has access to each “live” service endpoint program instance, which is often not the case. Additionally, it is not always financially practical to setup a physical “test” environment to allow for web service client testing.
A considerable drawback to alternate methods for testing on-demand client programs during development relates the capability of the computing infrastructure available to the development team. During the development of web services, it often is not realistic to assume the development team will have access to the other web services to which their new program must interface. Although a typical web service may be emulated in a rudimentary sense, it is often not possible to vary or change the simulated output from the various web services without extra programming and development.
Another approach which allows full testing across a variety of scenarios and test cases requires installation of a local copy of the service environment to make the various needed endpoints accessible to the client program under development, which may require installation of an entire on-demand infrastructure, including database programs, custom programs, computing platforms, disk arrays, etc. This can be prohibitively expensive, and may not be within the skill capabilities of the development team as many of these system components may require experts for their installation and configuration.